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FOREWORD 


APJ,  lander  contract  to  HQs,  AMCCOM,  has  initiated  the 
automation  of  the  LSA  Tasks  (MIL-STD-1388-1)  and  the  assessment 
of  the  ILS  elements  (AR  700-127)  .  A  major  goal  is  to  unify 
military  and  contractor  approach  to  the  perfoannance  of  ILS  and 
LSA. 


Detailed  to  meet  all  requirements  of  ILS  and  LSA^  the 
automated  process  will  continue  to  provide  the  flexibility  in 
selecting  tasks  and  elements  to  be  addressed  at  each  life  cycle 
stage.  A  major  advantage  of  this  approach  is  to  insure  that  the 
application  of  each  task  element  is  consistent  with  prescribed 
Army  policies  and  procedures . 

This  report  is  one  of  a  series  presenting  the  Structured 
Analysis  of  the  respective  LSA  Task  and  ILS  Element.  Structured 
Analysis  comprises  a  description  of  the  process  being  automated  in 
terms  which  facilitate  system  design  and  subsequent 
progr2unming .  It  is  increasingly  the  preferred  approach  in  both 
industry  and  Government. 

This  Technical  Note  reports  on  the  Data  Flow  Diagrams  (DFDs) 
of  LSA  Task  Subtask  301.2.5,  "Participate  in  Formulating  Design 
Alternatives"  and  provides  definitions  of  the  processes,  data 
flows,  data  stores,  and  external  entities  involved  on  each  DFD 
(Annexes  A  and  B)  .  The  report  provides  an  overview  of  the  LSA 
Task  analysis  procedures  and  a  guide  to  the  overall  process 
development . 

To  view  this  work  in  context,  this  report  also  presents  a 
brief  overview  of  Structured  Analysis  and  its  place  in  the 
overall  systems  development  process.  Additionally,  Annex  C 
provides  a  brief  working  description  of  Structured  Systems 
Analysis  Fundaunentals .  The  overview  and  certain  portions  of  the 
introductory  text  are  repeated  verbatim  in  every  report  in  this 
series  so  that  each  report  is  free  standing. 
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INTRODUCTION 


PURPOSE 

The  purpose  of  this  report  series  is  to  present  the  results 
of  the  APJ  efforts  under  Contract  DAAA21-86-D-0025  for 
coordination  with  the  AMCCOM  Program  Manager  prior  to  in-depth 
programming  of  ILS  and  LSA  functions  and  processes.  "Participate 
in  Formulating  Design  Alternatives"  (LSA  Subtask  301.2.5)  is 
addressed  in  this  report. 


BACKGROUND 

The  Department  of  the  Army  has  a  requirement  for  management 
control  over  contractor  and  Government  agency  response  to  the 
requirements  of  AR  700-127,  "Integrated  Logistic  Support",  and 
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MIL-STD-1388-1,  "Logistic  Support  Analysis".  HQs  AMCCOM  has 
initiated  action  to  structure  each  of  the  LSA  tasks,  the 
assessment  of  each  ILS  element,  the  foonn  of  the  results,  and  the 
detailed  processes  to  insure  consistency  with  current  Army 
policies,  procedures,  and  techniques.  This  approach  (undertaken 
by  AMCCOM  and  APJ)  will  insure  uniformity  in  efforts  and 
products,  reproducibility  of  analyses,  and  a  well-defined 

structure  which  can  be  coordinated  among  all  participants  in  the 
logistic  process  to  arrive  at  common  understanding  and  procedures. 
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SCOPE 


This  report  summarizes  the  results  of  the  Structured  Analysis 
of  LSA  Task  301,  "Functional  Requirements  Identification", 
Subtask  301.2.5,  "Participate  in  Formulating  Design  Alternatives", 
and  presents  the  associated  Data  Flow  Diagrams  (DFDs)  developed 
from  the  Structured 

Analysis.  The  portions  of  the  Data  Dictionary  relating  to  labels, 
names,  descriptions,  processes,  data  flows,  data  stores,  and 
external  entities  are  included  in  their  present  degree  of 
completeness.  (The  Data  Dictionary  is  a  "living  docviment"  that 
evolves  through  analysis  and  design  process) . 

To  place  this  work  in  context,  this  report  presents  a  brief 
overview  of  Structured  Analysis  emd  its  place  in  the  overall 
systems  design  process  to  assist  the  reader  who  may  not  be  fully 
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briefed  on  the  symbols  and  conventions  used.  It  is  supported  by 
Annex  C,  which  defines  each  element  in  Structured  Analysis. 

LSA  SUBTASK  301.2.5  DESCRIPTION 

LSA  Subtask  301.2.5.  concerns  logistics  performance  in  the 
formulation  and  logistic  evaluation  of  design  alternatives 
established  to  correct  design  requirements  or  operations  and 
maintenance  task  requirements.  In  the  same  way,  design 
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alternatives  which  reduce  or  simplify  functions  requiring  logistic 
support  resources,  shall  be  analyzed.  Task  inputs  stated  by  MIL- 
STD-1388-1A  are  as  follows: 


1.  Any  documentation  requirements  over  and  above  LSAR 
data  such  as  functional  flow  diagrams  or  design 
recommendation  data  resulting  from  the  task 
identification  process . 

2 .  Identification  of  system/equipment  hardware  and 
software  on  which  this  task  will  be  performed  and 
the  indenture  levels  to  which  this  analysis  will  be 
carried. 

3.  Identification  of  the  levels  of  maintenance  which 
will  be  analyzed  during  performance  of  this  task  to 
identify  functions  and  tasks . 

4.  Description  of  system/equipment  concepts  under 
consideration 

5 .  FMECA  results 

6.  Use  study  results  from  Task  201. 


Task  output  comprises  the  identification  of  design 
deficiencies  requiring  redesign  as  a  result  of  the  functional 
requirements  and  operations  and  maintenance  task  identification 
process. 

The  task  definitions  for  the  LSA  Task  301  and  the  LSA  subtask 
301.2.5  descriptions  from  MIL-STD-1388-1A  are  presented  as  Annex 
A. 
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APPROACH 


The  APJ  approach  to  Structured  Analysis  of  the  LSA  task  is: 

1.  Scope  the  process  defined  in  MIL-STD-ISSS-IA 

in  the  context  of  tne  other  LSA  tasks . 

2.  Review  the  guidance  provided  in  AMC  PAM  700-11, 

"Logistics  Support  J^alysis  Review  Team  Guide" . 

3.  Review  the  applicable  Data  Item  Descriptions  (DIDs) 

from  the  Acquisition  Management  Systems  and  Data 
Requirements  Control  List  (AMSDL)  published  by  the 
Department  of  Defense. 

4 .  Review  all  source  documents  referenced  in  the 
AMSDL  as  applicable  to  the  referenced  DIDs  of 
interest . 

5 .  Apply  staff  experience  in  logistics  support 
analysis  to  assure  that  the  intent  of  the  task  has 
been  addressed. 

6.  Validate  results  in  discussions  with  Army 

activities  and  personnel  directly  involved  in  the 
applicable  or  related  LSA  tasks. 

Structured  Analysis  and  preparation  of  Data  Flow  Diagrams 
(DFDs)  was  further  assisted  by  the  application  of  Structured 
Analysis  software.  Licensed  by  Index  Technology  Corporation, 
Excelerator  provides  for  automated  tracking  of  names,  labels, 
descriptions,  multiple  levels  of  detail  in  the  data  flow  diagrams, 
and  industry  standards  in  symbols  and  diagramming  practices . 

Following  completion  of  the  draft  DFDs,  the  diagrams  and  data 
dictionary  were  made  available  to  working  Army  logisticians 
currently  (or  recently)  directly  involved  in  the  application  of 
the  same  LSA  tasks  in  current  Army  development  programs. 
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Comments  were  solicited  relative  to  the  logic  of  the  processes 
described,  the  scope  and  details  of  the  indicated  approaches,  and 
the  outputs  implied  by  the  LSA  task  requirements. 

Draft  products  were  well  received  by  the  external  reviewers, 
and  requests  have  been  made  for  copies  of  the  DFDs  for  in-house 
use  in  organizing  ILS  and  LSA  efforts .  Comment  was  also  received 
that  the  DFDs  will  be  a  useful  training  tool  for  apprentice 
logisticians,  since  they  provide  an  overall  picture  of  the  total 
task  and  a  uniform  approach  to  its  fulfillment. 


STRUCTURED  ANALYSIS  AND  DESIGN: 

Structured  Analysis  and  Structured  Systems  Design  evolved 
from  the  need  to  define  and  demonstrate  the  underlying  logical 
functions  and  requirements  of  large  systems .  The  concept  of 
Structured  Analysis  involves  building  a  logical  (non-physical) 
model  of  a  system,  using  graphic  techniques  which  enable  users, 
analysts,  and  designers  to  get  a  clear  and  common  picture  of  the 
system  and  how  its  parts  fit  together  to  meet  the  user's  needs. 
It  is  followed  by  structured  design,  and  then  by  programming,  and 
test  and  validation.  Annex  C  provides  a  brief  description  and 
guide  to  the  fundamentals  of  a  Structured  Systems  Analysis. 

The  Structured  Analysis  and  Structured  Systems  Design 
process,  sometimes  referred  to  as  "Structured  Systems  Analysis 
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and  Design  (SSAD)”,  is  well  documented  and  widely  utilized  in 
Government  and  industry. 

As  stated  in  "The  Practical  Guide  to  Structured  Systems 
Design"  (Meilir  Page- Jones,  Prentice-Hall,  Englewood  Cliffs,  NJ, 
1980)  : 

..."Structured  Design  is  disciplined  approach  to  computer 
system  design,  an  activity  that  in  the  past  has  been  notoriously 
haphazard  and  fraught  with  problems. 

"1.  Structured  Design  allows  the  form  of  the  problem  to 
guide  the  form  of  the  solution. 

"2.  Structured  Design  seeks  to  conquer  the  complexity  of 
large  systems  by  means  of  partitioning  the  system  into  "black 
boxes, "  and  by  organizing  the  black  boxes  into  hierarchies 
suitable  for  computer  implementation. 

"3.  Structured  Design  uses  tools,  especially  graphic  ones, 
to  render  systems  readily  understandable. 

"4.  Structured  Design  offers  a  set  of  strategies  for 
developing  a  design  solution  from  a  well  defined  statement  of  a 
problem. 

"5.  Structured  Design  offers  a  set  of  criteria  for 
evaluating  the  quality  of  a  given  design  solution  with  respect  to 
the  problem  to  be  solved. 

"Structured  Design  produces  systems  that  are  easy  to 
understand,  reliable,  flexible,  long  lasting,  smoothly  developed, 
and  efficient  to  operate  -  and  that  WORK...." 

The  organization  of  Structured  Analysis  and  its  relationship 
to  Structured  System  Design  is  shown  on  Figure  1. 


LSA  SUBTASK  301.2.5  -  DATA  FLOW  DIAGRAMS 

The  Data  Flow  Diagram  is  a  tool  that  shows  flow  of  data. 
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Figure  1 


REVIEW/CRITIQUE/ACCEPTANCE  OF  DFD 


Structured  Analysis  and  Structured 
Systems  Design  Organization 


7 


i.e.,  data  flows  from  sources  and  is  processed  by  activities  to 
produce  intermediate  or  final  products. 

The  DFD  provides  a  useful  and  meaningful  partitioning  of  a 
system  from  the  viewpoint  of  identification  and  separation  of  all 
functions,  actions,  or  processes  so  that  each  can  be  introduced, 
changed,  added,  or  deleted  with  minimal  disruption  of  the  overall 
program,  i.e.,  it  emphasizes  the  underlying  concept  of  modularity 
and  identifiable  transformations  of  data  into  actionable 
products . 

Two  (2)  DFDs  have  been  developed  to  structure  the  LSA  subtask 
relative  to  participation  in  the  formulations  and  logistic 
evaluation  of  design  alternatives: 

1.  301.2.5  Overview  (or  Top  Level) 

2.  301.2.5.1A  Identify  Design  Deficiencies 

Each  DFD  is  keyed  to  the  specific  task  (LSA,  in  this  case) 
through  the  identification  number  assigned  in  the  lower  right 
hand  box.  The  Alpha  codes  indicate  the  level  of  indenture  or 
explosion  below  the  top  level,  i.e.,: 

Top  Level . LSA  DFD  301.2.5 

First  Indenture . LSA  DFD  30 1.2. 5. lA 

Each  DFD  makes  reference  to  the  basic  LSA  task  it  addresses, 
as  well  as  the  level  of  indenture  (explosion)  of  the  DFD.  For 
example,  the  first  or  top  level  DFD,  "301.2.5”,  refers  to  the 
paragraph  in  MIL-STD-138S-1A  which  describes  the  task.  One  of  the 
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processes  (bubbles)  on  the  top  level  diagram  (301.2.5.1, 
Consolidate  Deficiency  in  OPS/SUP  Functional  Report)  is  expanded 
and  identified  as  "301 .2 .5 . lA" ,  a  second  level  of  301.2.5.1 
(Alpha  "A"  indicates  the  second  level) . 

Four  standard  symbols  are  used  in  the  drawing  of  a  DFD  (see 
Figure  2) . 

A  copy  of  each  DFD  is  presented  in  Annex  B,  accompanied  by 
the  Data  Dictionary  process  elements .  Each  entry  made  in  the 
DFDs  has  a  corresponding  entry  in  the  Data  Dictionary,  immediately 
following  each  of  the  DFDs . 

This  Technical  Note  presents  only  those  Data  Dictionary 
entries  necessary  for  the  coordination  of  the  overall  concept  and 
details  of  the  processes.  To  facilitate  review  of  the  diagrams, 
data  flow  identifications,  process,  external  entities  and  data 
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Store  descriptions  are  provided. 

As  the  DFDs  progress  through  Structured  System  Design,  the 
Data  Dictionary  will  continue  to  be  expanded  and  completed.  Since 
they  are  wor)cing  documents  rather  than  final  submissions,  only 
minimum  effort  has  been  devoted  to  editorial  niceties,  e.g., 
spelling,  typography,  etc. 
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REPRESENTS  A  PROCESS,  FACTION, 
OR  ACTION 


REPRESENTS  A  DATA  STORE  OR  A 
DATA  FILE  -  OFTEN  IDENTIFIED  AS 
REPOSITORY  OF  INFOPJ1ATION  OF  A 
SPECIFIC  TYPE 


REPRESENTS  A  DATA  ELEMENT  FLOW 
INDICATING  OUTPUT  FROM  ONE 
PROCESS  AND  INPUT  TO  ANOTHER 
PROCESS 


REPRESENTS  AN  EXTERNAL  ENTITY  - 
AN  ACTIVITY  NOT  A  PART  OF  THE 
SYSTEM/PROCESS  BEING  MODELED. 


Figure  2.  STANDARD  DFD  SYMBOL  DEFINITIONS 
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ANNEX  A 


LSA  TASK  301 

FUNCTIONAL  REQUIREMENTS  IDENTIFICATION 


ANNEX  A 


LSA  TASK  301 

FUNCTIONAL  REQUIREMENTS  IDENTIFICATION  1/ 


301.1  PURPOSE:  To  identify  the  operations  and  support 
functions  that  must  be  performed  for  each  system/ equipment 
alternative  under  consideration  and  then  identify  the  tasks  that 
must  be  performed  in  order  to  operate  and  maintain  the  new 
system/equipment  in  its  intended  environment. 

301.2  TASK  DESCRIPTION: 

301.2  Participate  in  formulating  design  alternatives  to  correct 
design  deficiencies  uncovered  during  the  identification  of 
functional  requirements  or  operations  and  maintenance  task 
requirements.  Design  alternatives  which  reduce  or  simplify 
functions  requiring  logistic  support  resources  shall  be  analyzed. 


1/  Abstracted  verbatim  from  MIL-STD-1388-1A,  April  11,  1983, 
Pages  36-37. 
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ANNEX  B 


PARTICIPATION  IN  FORMULATING  DESIGN  ALTERNATIVES 

SUBTASK  301.2.5 

DATA  FLOW  DIAGRAMS  AND  PROCESS  DATA  DICTIONARY 


toe 


B-1 


DATE:  11-APR-S9 
TIME:  09:28 


AEJ  PROJECT  968 
PROCESS  DEFINITIONS 


PAGE  1 
EXCELERATOR  1.8 


Nam*  Labal  Daaeriptlon 


301.2.5.1  CONSOLIDAT  THIS  PROCESS  CONSOLIDATES  DESIGN  DEFICIENCIES  ONCOVERED  DORING  THE 

DEFICIEMCT  IDENTIFICATION  OF  FUNCTIONAL  REQUIREMENTS  ANALTSIS  (TASK  301.2.1),  AMD 
IN  OPS/SUP  THE  OPERATIONAL  AMD  MAIMTEMAMCB  TASK  REQUIREMENTS  (TASK  301.2.4.1, 
FUNCTIONAL  301.2.4.2,  fi  301.2.4.3)  CONSIDERING  THE  RISKS  IDENTIFIED  DURING  THE  RISK 
RQMNTS  ANALTSIS  (TASK  301.2.3).  SEE  EXPLOSION  DFD  301.2.5.1A1  FOR  DETAILED 

PROCESSES  RELATED  TO  THIS  PROCESS. 

ACRONTN: 

LSA  -  LOGISTIC  SUPPORT  ANALTSIS 

DOCUMEMTATZOM  GENERATED  AS  A  RESULT  OF  THE  LSA  TASKS  SBONM  AS 
INPUTS  TO  THIS  PROCESS  IN  DATA  FLON  DIAGRAM  301. 2. SA  ARE  REVIENED  AMD 
AMALTZED  TO  IDENTIFT  AMD  DOCUMENT  THE  EXISTENCE  OF  DESIGN  DEFICIEMCIES 
OR  STSTEM/EQUIPMBNT  CHARACTERISTICS  SBONN  TO  BE  SUPPORT  RESOURCE 
INTENSIVE . 

THE  STSTEM/EQUIPMBNT  DESIGN  DEFIECIENCISS  DOCUMENTATION,  DEVELOPED 
IN  PROCESS  301.2.S.1A1,  ARE  REVEINED,  AMALTZED  AND  CATEGORIZED  INTO  THE 
DESIGN  AREA  OF  INTEREST  INCLUDING  BUT  MOT  LIMITED  TO  THE  FOLLOWING: 

1)  KATERIELS 

2)  TBCHNOLOGT 

3)  OPERATIONS 

4)  OPERATIONAL  LIMITS 

5)  ENVIROHMENTAL  CRITERIA. 

301.2.5.1A3  SORT  ALL  THIS  PROCESS  SORTS  THE  DESIGN  DEFICZENCIES  AND  ESTABLISHED  DESIGN 

DEFICIENCS  CATEGORIES  ACCORDING  TO  THE  SEVBRITT  OF  THE  DEFICZENCT,  AND  PROJECTS  THE 
BT  DESIGN  RESOURCES  REQUIRED  TO  OVERCOME  THE  DEFICIEMCT.  THIS  DATA  WILL  BE  THE 
AREA  BASIS  FOR  FORMULATING  DESIGN  ALTERNATIVES  TO  CORRECT  DEFICIENCIES  IN  THE 

MOST  COST-EFFECTIVE  MANNER. 

301.2.5.2  PARTC'PATE  ACRONTM: 

IN  FORMULA  ILS  -  INTEGRATED  LOGISTIC  SUPPORT 

TION 

DESIGN  THIS  PROCESS  INVOLVES  PARTICIPATION  IN  A  DESIGN  REVIEW, 

ALTERMATIV  FORMULATING  DESIGN  ALTERNATIVES  TO  CORRECT  DESIGN  DEFICIENCIES.  ITS 
GOAL  IS  TO  REDUCE  OR  SZMPLIFT  FUNCTIONS  REQUIRING  LOGISTIC  SUPPORT 
RESOURSES  TO  PROVIDE  THE  BEST  RETURN  ON  THE  ILS  INVESTMENT  WHILE  MEETZMO 
THE  SISTEMS  READINESS  OBJECTIVE. 

301.2.5.3  REAPPLICTM  ACRONIMS : 

OF  FMECA/  FMECA  -  FAILURE  MODE,  EFFECTS  AND  CRITICALITI  ANALYSIS 

RCM  TO  PRO  RCM  -  RELIABILITY  CENTERED  MAINTENANCE 

POSED  DSGN 

CHANGES  THIS  PROCESS  IS  A  REAPPLZCATION  OF  THE  FAILURE  MODE,  EFFECTS  AMD 

CRITICALITY  ANALYSIS  (TASK  301.2.4.1)  TO  THOSE  ITEMS  WHICH  ARE 
ADDED,  CHANGED,  OR  IMPACTED  THROUGH  THE  REDESIGN  PROCESS.  THE  FMECA  IS 
FOLLOWED  BY  A  REPEAT  OF  TBS  RELIABILITY  CENTERED  MAIMTEMANCB  (RCM) 
ANALYSIS  (TASK  301.2.4.2)  ON  THE  SAME  ITEMS. 


301.2.S.1A2  IDENTIFY 

DESIGN 
AREAS  OF 
INTEREST 


301.2.5.1A1  IDENTIFY 

DESIGN 
OPS/SUP/ 
FUNC/DBF 
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ACRONTMS: 

FMECA  -  FAILURE  MODE,  EFFECT,  C  CRITICALLITT  ANALYSIS 
RCM  -  RELIABILITY  CENTERED  KAINTEMAMCE 

THE  CHARACTERISTICS  OF  ONE  OR  MORE  DESIGN  ALTERNATIVES  THAT  WILL 
CORRECT  DEFICIENCIBS  DISCOVERED  DURING  IDENTIFICATION  OF  SUPPORT 
FUNCTIONS,  SUPPORT  OPERATIONS  AND  MAINTENANCE  TASK  REQUIREMENTS,  AS 
WELL  AS  CHARACTERISTICS  OF  ALTERNATIVES  WHICH  WILL  REDUCE  OR  SIMPLIFY 
FUNCTIONS  REQUIRIMG  LOGISTIC  SUPPORT  RESOURCES.  THE  CHARACTERISTICS  OF 
EACH  ALTERNATIVE  DESIGN  BECOMES  THE  BASIS  FOR  THE  REPEAT  OF  FMBCA/RCM 
EFFORT (PROCESS  301.2.5.3). 

A  DOCUMENT  OR  SET  OF  DOCUMENTS  IDENTIFYING  THOSE  SYSTEM/EQUIPMENT 
CHARACTERISTICS  SHOWN  TO  BE  LOGISTIC  SUPPORT  RESOURCE  INTENSIVE,  HAVING 
A  HIGH  PROBABILITY  OF  FAILURE  OR  CANNOT  BE  MAINTAINED  WITH 
EXISTING/UNIQUE  SUPPORT  RESOURCES. 

ACRONYM: 

DMBA  -  DAMAGE  MODE  AMO  EFFECT  ANALYSIS 

THE  RESULTS  OF  A  DAMAGE  MODE  AMD  EFFECT  ANALYSIS  (DIBA)  POINTS  OUT 
THE  VULNERABILITY  CHARACTERISTICS  OF  TBS  STSTSM/SQUIPIBMT  DURING 
WARTZMB  OPERATIONS  AND  THE  CRITERIA  FOR  A  SURVTVABILZTY  EMHAMCEMEMT 
PROGRAM. 

REFERENCE:  MIL-STD-1629A,  "FAILURE  MODE  6  EFFECT  ANALYSIS,”  TASK 

104. 


A  LISTING  OF  DESIGN  OEFZCIENCZBS  lOENTIFZBD  IN  PROCESS  301.2.5.1A1 
THAT  HAS  BEEN  CATEGORIZED  AS  TO  THE  APPLICABLE  AREA  OF  DESIGN  INTEREST 
AND  ITS  SEVERITY  LEVEL  AS  DEFINED  IN  MIL-STD-1629A. 

REFERENCE:  MIL-STD-1629A  "FAILURE  MODE,  EFFECTS,  AND  CRITICALITY 

ANALYSIS . " 

THE  FAILURE  MODES,  EFFECTS  AMD  CRITICALITY  ANALYSIS  WITH 
MAINTENANCE  INFORMATION  PROVIDES  THE  ANALYTICAL  DATA  NECESSARY  TO 
DETERMINE  AND  DOCUMENT  CORRECTIVE  MAINTENANCE  TASK  REQUIREMENTS  AND 
IDBMTZFICATIOM  OF  THOSE  MAINTAINABILITY  DESIGN  FEATURES  REQUIRING 
CORRECTIVE  ACTION. 

REFERENCE:  HZL-8TD-1629A,  "FAILURE  MODE,  EFFECTS  AMD  CRITZCALITY 
ANALYSIS",  LSA  SUBTASK  301.2.4.1 


ACRONYMS: 

FMECA  -  FAILURE  MODE,  EFFECTS  AND  CRITZCALITY  ANALYSIS 
LSAR  -  LOGISTICS  SUPPORT  ANALYSIS  RECORD 
FMECA  DATA,  WHICH,  WHEN  GENERATED  IN  ACCORDANCE  WITH  THE 
REQUIREMENTS  IN  MILITARY  STANDARD  MZL-8TD-1629A  OR  WHEN  EXTRACTED  FROM 
A  LEAR  DOCUMENT,  PROVIDES  POTENTIAL  IMPACT  OF  BACH  FUNCTIONAL  OR 
HARDWARE  FAZLURE  ON  MISSION  SUCCESS,  PERSONNEL  AND  SAFETY  SYSTEMS, 
SYSTEM  PERFORMANCE,  MAINTAINABILITY,  AND  MAINTENANCE  REQUIREMENTS. 

REFERENCE:  MZL-STD-1629A,  "FAILURE  MODE,  EFFECTS  AMD  CRITZCALITY 
BMALTEZS". 
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THE  RESULTS  OF  FERFORMZNG  A  FMBCA/RCM  EFFORT  ON  THOSE  PROPOSED 
ALTERNATE  STSTBM/EQUZPMBNT  DESZGNS  OR  RSDBSZGNS  NOT  PREVZOUSLT  SUBJECT 
TO  TBZS  EFFORT  ARE  REPROCESSED  THROUGH  PROCESS  301.2.S.1  FOR  ANALYSTS 
AND  POSSZBLE  REVEUITZON  OF  ANY  NEW  DESZGN  DEFZCZENCZES . 

REFERENCE;  MZL-STD-1629A  AND  AMC-P-750-2 


ACRONYMS: 

FMECA  -  FAZLORE  MODE,  EFFECT  AMD  CRZTZCALZTY  ANALYSTS 
RCM  -  RELIABZLZTY  CENTERED  MAINTENANCE 

THE  DATA  ACCUMULATED  AS  PART  OF  TEE  PROCESS  301.2.5.1, 

"COMSOLODAXED  DEFZCZENCY  ZN  OPERATZOMS/SUPPORT  FUMCTZOHAL  BBQUXREMBNTS" 
EFFORT,  INCLUDING  THE  FMECA  -  MAINTENANCE  INFORMATION,  SUPPORT  FUNCTION, 
UNIQUE  SUPPORT  FUNCTIONS,  PREVENTIVE  MAINTENANCE  TASKS  (RCM) ,  RISKS  ZN 
SATISFYING  REQUIREMENTS,  AND  THE  QUAMTZTATIVB  SUPPORTABZLZTY  FACTORS, 
CONSTITUTE  THE  BASIC  INPUTS  TONARD  ESTABLISHING  DESIGN  ALTERNATIVES 
REQUIRED  TO  CORRECT  DESIGN  DEFZCZENCZES  IN  THE  SYSTEM/EQUIPMENT . 

THE  RESULTS  OF  SUPPORT  OPERATIONS  AND  OTHER  SUPPORT  TASKS 
lOBMTZFIEO  THROUGH  ANALYSIS  OF  MEN  SYSTEM/EQUIPMENT  FUNCTIONAL 
REQUIREMENTS  AMD  INTENDED  OPERATIONS  NOT  IDENTIFZED  ZN  A  FMECA  OR  RCM 
EFFORT. 

REFERENCE;  LSA  TASK  301.2.4.3 

ACRONYM; 

FMECA  -  FAILURE  MODE,  EFFECTS  AND  CRITICALITY  ANALYSIS 

THE  ESTABLISHMENT  OF  PREVENTIVB  MAINTENANCE  (SCHEDULED  MAZNTNANCE) 
TASKS  FOR  A  GIVEN  SYSTEM/EQUZPMBNT,  OR  CONCLUDING  THAT  MAINTENANCE 
TASKS  CAN  BE  PERFORMED  ON  A  "ON  CONDITION"  (UNSCHEDULED)  BASIS  IS  NHOLLY 
PREDICATED  UPON  THE  INFORMATION  DEVELOPED  AND  NOTED  IN  A  COMPLETED 
FMECA  DOCUMENT  FOR  THE  SYSTEM/EQUZPMBNT. 

ITEMS  OF  A  SYSTEM/EQUIPMENT  IN  SEVERITY  CLASSIFICATION  CATEGORY  I 
(CATASTROPHIC)  OR  CATEGORY  II  (CRITICAL),  AS  DEFINED  IN  THE  CRITICALITY 
ANALYSIS  PORTION  OF  A  FMECA  EFFORT,  REQUIRES  ALL  MAINTENANCE  EFFORTS  TO 
BE  PERFORMED  ON  A  "PREVENTIVE  MAINTENANCE"  (SCHEDULED)  BASIS,  NBEREAS, 
ITEMS  ZN  THE  CATEGORY  III  (MARGINAL)  AMD  CATEGORY  IV  (MINOR)  SEVERITY 
CLASSIFICAZION  CAM  BE  PERFORMED  ON  A  "ON  CONDITION”  (UNSCHEDULED) 
MAINTENANCE  LAS IS . 

DRIVERS,  SUCH  AS  COSTS,  SUPPORTABZLITY,  AND  READINESS  COULD  MAKE 
CATEGORIES  III  S  ZV  ITEMS  PREVENTIVE  MAINTENANCE  ITEMS.  THEREFORE, 

THESE  ITEMS  AS  NELL  AS  THE  CATEGORY  I  C  ZI  ITEMS  CAM  BE  CONSIDERED 
DESIGN  DIFICZEMCZES  SUBJECT  TO  CORRECTIVE  ACTIONS. 

REFERENCE;  AMC-P  750-2,  LSA  PROCESS,  CHAPTER  4 
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DATA  APPLICABIE  TO  OPERATING  REQUIREMENTS,  NUMBER  OR  SYSTEMS 
SUPPORTED,  TRANSPORTATION  FACTORS,  ALLOWABLE  MAINTENANCE  PERIODS,  AND 
ENVIRONMENTAL  REQUIREMENTS,  AS  A  MINIMUM,  WHICH  HAVE  BEEN  QUANTIFIED  TO 
ESTABLISH  SUPPORTABILITY  FACTORS  RELATED  TO  THE  INTENDED  USE  OF  THE  NEW 
SYSTEM 

THE  RESULTS  OF  PREVIOUSLY  CONDUCTED  MISSION  AREA  AMD  WEAPON  SYSTEM 
ANALYSIS  WITH  QUANTIFIED  RELATIONSHIPS  BETWEEN  HARDWARE,  MISSION,  AMD 
SUPPORTABILITY  PARAMETERS  AMO  APPLICABLE  TO  THE  MEW  SYSTEM 
REFERENCE:  LSA  TASK  201.2.2 


ACRONYMS: 

FMECA  -  FAILURE  MODE,  EFFECTS  AMD  CRITICALITY  ANALYSIS 
LSAR  -  LOGISTICS  SUPPORT  ANALYSIS  RECORD 
RCM  -  RELIABILITY  CENTERED  MAINTENANCE 

RELIABILITY  CENTERED  MAINTEi'ANCE  <RCM)  DATA  DERIVED  FROM  THE  FMECA 
DATA  DOCUMENTED  IN  THE  LSAR.  THIS  INFORMATION  CONSTITUTES  THE  BASIS  IN 
THE  DEVELOPMENT  OF  THE  PREVENTIVE  MAINTENANCE  TASK  REQUIREMENTS  FOR  THE 
NEW  SYSTEM/EQUIPMEMT . 

REFERENCE:  LSA  TASK  301.2.4.2 

RECOIMBNDATIONS  WHICH  ARB  PROMULGATED  TO  OFFER  ALTERMATIVS 
SYSTEM/EQUIPMEMT  DESIGNS  THAT  WILL  CORRBCT  EXISTING  SHORTCOMINGS  IN  THE 
SUPPORT  FUNCTIONS.  INCLUDES  IDBNTIPICATIOM  IN  THE  FUNCTIONAL  DESIGN 
DEFICIENCY  WORK  SHEETS  OF  THE  AREAS  IN  A  NEW  SYSTEM/EQUXPMBNT 
REQUIRING  CORRECTIVE  FUNCTIONAL  DESIGNATION. 

MAY  INCLUDE  REDESIGN  ALTERNATIVES  CONSIDERED  AMD  RECOM4BNDED  TO 
REDUCE  Z3B  NUMBER  OF  REQUIRED  SUPPORT  FUNCTIONS,  SUPPORT  ACTIVITIES,  OR 

_  _  4  _  _ 

SUPPORT  RESOURCES,  OR  SIMPLIFY  (IF  REDUCTION  IS  NOT  POSSIBLE)  SUPPORT 
FUNCTIONS  THAT  ARE  RESOURCE,  READINESS,  OR  COST  DRIVERS. 

IDENTIFICATION  AND  DOCUMENTATION  OF  THOSE  RISKS  ASSOCIATED  WITH  AND 
AFFECTING  THE  PERFORMANCE  OF  SPECIFIC  SUPPORT  FUNCTIONS,  UNIQUE  SUPPORT 
FUNCTIONS  (IF  ANY),  AND  THE  PREVENTIVE  MAINTENANCE  TASKS. 

IN  LIKE  MANNER  DOCUMENTATION  OF  THOSE  RISKS  ASSOCIATED  WITH  SUPPORT 
EFFORTS  SUBJECT  TO  COST  DRIVERS. 

REFERENCE:  LSA  TASK  301.2.3 


ACRONYMS; 

FMECA  -  FAILURE  MODE,  EFFECTS  AND  CRITICALITY  ANALYSIS 
LSAR  -  LOGISTICS  SUPPORT  ANALYSIS  RECORD 
RCM  -  RELIABILITY  CENTERED  MAINTENANCE 
AMY  INFORMATION,  WHETHER  IT  BE  TECHNICAL  OR  OTHER,  APPEARING  IN  THE 
EXISTING  LSAR  FILE  AND  WARRANTING  CONSIDERATION  IN  THE  PERFORMANCE  OF 
THE  FMECA/RCM  PREPARATION  FOR  EACH  PROPOSED  SYSTEM/EQUIPMEMT  ALTERNATE 
DESIGN 
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DOCUMENTED  AND  IDENTIFIED  SUPPORT  FUNCTIONS  NECESSARY  TO  MAINTAIN  A 
NEW  SYSTEM/EQUIPMBHT  IN  A  FUNCTIONAL  AND  OPERATIONAL  CONDITION,  WITHIN 
ITS  INTENDED  OPERATIONAL  ENVIRONMENT.  PEACETIME  OR  WARTIME  (OR  BOTH) 
OPERATIONAL  CONDITION,  INCLUDING  THE  SPECIFIC  EQUIPMENT  FUNCTION/DESIGN 
CHARACTERISTIC  REQUIRING  SUPPORT 

IDENTIFIED  AND  DOCUMENTED  INADEQUACIES  OF  A  SPECIFIC  SUPPORT 
FUNCTION,  OR  INABILITY  TO  ESTABLISH  A  SUPPORT  FUNCTION  FOR  A  GIVEN 
CONDITION  OF  THE  SYSTEM/EQUIFMBNT 
REFERENCE:  LSA  TASK  301.2.1 

SUPPORT  FXmCTIONS  WHICH  CAN  BE  CONSIDERED  "UNIQUE”  WHEN  COMPARED 
TO  EXISTING  OR  SIMILAR  SYSTEMS  EQUIPMENT 

NEW  SYSTEM/EQUIPMENT  CONTAINING  NEW  DESIGN  TECHNOLOGY,  HEW 
OPERATIONAL  CONCEPTS,  OR  WHICH  ARE  SUPPORTABILITY,  COST,  OR  READINESS 
DRIVERS 

IDENTIFIED  AND  DOCUMENTED  INADEQUACIES  OF  A  SPECIFIC  SUPPORT 
FUNCTION  OR  INABILITY  TO  ESTABLISH  A  SUPPORT  FUNCTION  FOR  A  GIVEN 
"UNIQUE"  CONDITION  OF  THE  SYSTEM/EQUIPMBNT 
REFERENCE:  LSA  TASK  301.2.2 
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LSAR  FILE  ACRONYMS: 

ZLS  -  IMTBSRATED  LOGISTIC  SUPPORT 
LSA  -  LOGISTIC  SOPPORT  AMALTSIS 
LSAR  -  LOGISTIC  SUPPORT  ANALYSIS  RECORD 

THE  LOGISTIC  SUPPORT  ANALYSIS  FILE  (LSAR)  OR  RECORD  HOLDING  AREA 
CONTAINS  LSA  TASK  REPORTS  OR  THE  EQUIVALENT  (LSAR  MASTER  RECORD  SHEET 
INFORMATION  OR  LSAR  REPORTS)  .  MHEM  THE  SYSTEM  IS  AUTOMATED  IT  CONTAINS 
LOGISTICS  DATA  NBICB  CAM  BE  USED  TO  ASSESS  VARIOUS  ILS  ELEMENTS. 

MZL-STD  13e8-lA  AND  138e-2A  SHOULD  BE  LOOKED  AT  FOR  COMPLETE  OUTPUTS. 
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DEV/ALT/OSON  DEVELOP  ACRONYMS: 

ALTRMATIV  LSA  -  LOGISTICS  SUPPORT  ANALYSIS 

DESIGN/ 

REDESIGNS  THE  PRIMARY  FUNCTION  OF  TBE  LOGISTICIAN  IN  THIS  LSA  TASK  IS  TO 

PARTICIPATE  IN  FORMULATING  DESIGN  ALTERNATIVES  TO  CORRECT  DESIGN 
DEFICIENCIES  UNCOVERED  DURING  THE  IDENTIFICATION  OF  FUNCTIONAL 
REQUIREMENTS  OR  OPERATIONS  AND  MAINTENANCE  TASK  REQUIREMENTS. 

THIS  EXTERNAL  ENTITY  REFERS  TO  THAT  ACTIVITY,  GROUP,  OR  OCCASION  IN 
WHICH  THE  DESIGN  REVIEN  TAKES  PLACE,  AND  ALSO  WHERE  THE  LOGISTICIAN  IS 
PARTICULARLY  INTERESTED  IN  XNTRODUCXMO  THOSE  FACTORS  WHICH  HAY  REDUCE  OR 
SIMPLIFY  FUNCTIONS  REQUIRING  LOGISTIC  SUPPORT  RESOURCES. 


ANNEX  C 

STRUCTURED  SYSTEMS  ANALYSIS 
Fundament  al s 


ANNEX  C 

STRUCTURED  SYSTEMS  ANALYSIS 
Fundamentals 


Structured  Systems  Analysis  (SSA)  has  recently  become  an 
industry  standard  for  generating  Data  Flow  Diagrams  (replacing 
"logic  diagrams"  or  "flow  charts")  to  aid  in  coordinating  the 
fxinctions  to  be  performed  by  a  computer  program  and  its 
associated  Inputs/Outputs  (I/O) .  During  the  SSA,  each  set  of 
"flow  charts”  can  be  checked  by  the  potential  user  to  assure  that 
there  is  complete  agreement  on  what  is  to  be  done  by  the 
program,  amd  how  it  is  to  be  accon^lished.  It  also  provides 
consideradsle  flexibility  for  updating  or  changing  the  program. 

Six  basic  elements  are  used  in  SSA: 

1 .  Process  (PRC) 

2.  Data  Flow  (DAF) 

3.  Data  Store  (DAS) 

4 .  External  Entity  (EXT) 

5.  Data  Flow  Diagram  (DFD) 

6.  Data  Dictionary  (DCT) 

PROCESS  (Represented  by  a  Circle) : 

A  function  or  operation  to  be  performed  which  cam  be 
explained  by  a  set  of  instructions  representing  a  single  task, 
e.g.,  "calculate  interest  on  a  loam",  "prepare  a  draft  report". 

If  the  Process  description  is  too  complex  to  describe  in  a  few 
steps,  it  may  be  necessary  to  develop  a  lower  level  description 
(see  below) . 

DATA  FLOW  (Lines  interconnecting  Processes  or  I/Os) : 

Each  fimction  or  Process  cazmot  be  a  stand-alone  in  a 
complex  network.  To  have  amy  meaming  in  a  program,  each  process 
must  be  initiated  by  a  previous  action  amd/or  provided 
information  on  which  to  act.  Furthermore,  a  Process  must  result 
in  an  output  which  is  the  input  to  the  next  logical  Process. 

These  inputs,  outputs,  or  initiating  actions  are  identified  as 
Data  Flows,  amd  are  represented  by  the  Data  Flow  lines  indicating 
its  point  of  origin  and  the  process  to  which  it  provides  data. 


C-1 


DATA  STORE  (Represented  by  two  parallel  lines) : 

Although  some  Processes  generate  data  used  as  input  to  a 
succeeding  Process,  there  is  often  a  need  to  "gather  or  collect" 
information  from  files  in  which  it  is  stored.  This  information 
may  come  from  em  external  source  (such  as  a  MIL-STD,  Army 
regulation,  historical  experience  files,  etc.),  or  an  internal 
source  or  file  in  which  data  is  temporarily  stored  for  use  by 
succeeding  processes.  These  Data  Stores  Cem  be  visualized  as  a 
"file  cabinet",  in  which  the  data  are  stored  for  later 
retrieval) . 

EXTERNAL  ENTITY  (Represented  by  a  Rectemgle) : 

Each  prograun  or  logical  process  must  have  an  initiating 
action,  a  "point"  of  disposition  of  the  results,  amd  possible 
input  guidance  or  instructions.  Each  of  these  have  authorities, 
fxinctions,  or  applications  which  are  independent  of  the  prograim 
Process  (although  required  by  the  prograon  Process)  .  Thus,  these 
activities,  agencies,  or  facilities  are  considered  "External 
Entities"  to  the  prograun. 

DATA  FLOW  DIAGRAM: 

The  general  arrangement  of  the  above  cam  be  readily  seen. 
First,  the  circle  or  Process  describes  what  has  to  be  done;  the 
interconnecting  lines  represent  the  Data  Flows,  together  with  the 
specific  description  of  all  I/Os.  The  Data  Stores  identify  the 
source  and/or  file  designation  of  a  data  base,  amd  the  External 
Entities  represent  those  activities  remote  from  the  Process, 
which  are  the  source  of  guidance  or  the  recipients  of  the 
program.  This  combination  of  Processes,  Data  Flows,  Data  Stores, 
amd  External  Entities  constitutes  a  "Data  Flow  Diagram" .  The 
unicjue  feature  of  the  Data  Flow  Diagram  (DFD)  is  that  each 
process  cam  be  considered  independently,  permitting  a  change  to 
be  made  in  one  Process  without  a  major  chamge  in  the  overall 
program . 

DATA  DICTIONARY: 

The  Data  Dictionary  consists  of  a  complete  description  of 
each  of  the  basic  elements.  For  the  Process,  it  contains  a 
step-by-step  description  of  what  has  to  be  performed.  The 
description  of  the  Data  Flow  identifies  the  nomenclature  of  the 
data,  a  detailed  description  of  its  content,  amd  its  source. 

The  Data  Stores  amd  External  Entities  are  described,  including 
possible  location. 


C-2 


The  Data  Dictionary  (a  living  document)  begins  with  a 
description  of  the  first  Process  and  is  continually  built-up  as 
the  Data  Flow  Diagrams  are  expetnded/  detailed^  euid  eventually 
completed. 

APPROACH  TO  PERFORMING  STRDCTUBED  SYSTEM  ANALYSIS; 

The  best  approach  to  Structured  Systems  Analysis  is  to 
assxome  that  the  program  consists  of  a  series  of  processes,  each 
of  which  are  to  be  assigned  to  an  inexperienced  suialyst.  Each 
amalyst  is  to  be  walked  through  the  assigned  process  of  the 
Progreua,  explaining  step-by-step  what  functions  have  to  be 
performed  or  what  actions  have  to  be  taken  to  accomplish  the 
process.  The  analyst  is  also  informed  where  the  information  is 
coming  from  (input  Data  Flow) ,  what  is  to  be  generated  by  each 
process  (output  Data  Flow) ,  where  the  data  base  may  to  be  found 
(Data  Stores) ,  and  who  to  contact  for  guidamce  (External 
Entities) . 

The  best  way  to  initiate  a  SSA  is  to  set  down  the  point  of 
origin  of  a  program,  its  final  goal  (s) ,  eind  the  intermediate 
fvinctions  or  actions  needed  to  get  from  beginning  to  goal.  Each 
step  should  be  considered  as  a  Process  -  some  may  be  sequential 
and  others  parallel.  Then,  the  steps  needed  to  accomplish  the 
Process  should  be  described.  If  the  description  is  conqplex  emd 
needs  intermediate  steps,  the  Process  is  then  a  camdidate  for  an 
"explosion".  That  is,  the  top  (or  upper)  level  Process  is 
considered  as  a  "project"  and  its  own  Data  Flow  Diagram  is 
prepared. 

When  writing  the  step-by-step  procedures  in  the  Process, 
certain  elements  of  data  (or  information)  must  be  made  available 
for  the  procedure.  Each  element  of  data  is  considered  as  am 
input  Data  Flow,  which  is  identified  amd  described.  The  product 
(or  result)  of  a  Process  is  an  output  Data  Flow  element. 

Each  Data  Flow  to  the  Process  must  originate  from; 

1 .  am  earlier  Process 

2.  a  Data  Store  (or  file) 

3.  am  External  Entity. 

These  sources  are  also  identified,  described  amd  put  into 
the  Data  Dictionary.  As  soon  as  the  last  portion  of  the  Data 
Flow  Diagram  has  been  described,  the  SSA  is  complete. 
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